New Gitea RCE Lets Repository Writers Plant a Git Hook to Run Shell Commands

Gitea, the self-hosted Git platform, has patched a critical remote code execution vulnerability. A user with ordinary repository write access can turn attacker-controlled patch content into a live Git hook and run shell commands as the Gitea service account.

Tracked asCVE-2026-60004(CVSS score: 9.8), the flaw affects Gitea versions 1.17 and later before 1.27.1 and is fixed in 1.27.1. The vulnerable API call requires authentication and repository write permission. But Gitea enables registration by default, so an outside visitor can create a normal account and repository on an unchanged installation, then exploit the bug without pre-existing credentials.

Upgrading to 1.27.1 is the fix. Gitea said on July 27 that Gitea Cloud instances would be upgraded automatically. Gitea's July 28 advisory does not say the flaw has been exploited in the wild, but it includes public proof-of-concept (PoC) code.

Disabling open registration can remove the public account-creation path while the update is deployed, but it does not fix the flaw or protect against existing users with repository write access.

The flaw was reported by security researcherShai Rod, who goes by NightRang3r. Gitea credits NightRang3r as the reporter in its advisory.

Gitea'saffected routeinvokesreqToken(), which rejects requests without a signed-in user. The no-prior-credentials path comes from the project'sdefault configuration, which leaves registration open, requires neither email nor manual approval, does not mark new users as restricted, and imposes no default repository-creation limit.

The bug sits in thePOST /api/v1/repos/{owner}/{repo}/diffpatchendpoint. According to Gitea'ssecurity advisory, the endpoint applies a supplied patch inside a shared bare temporary clone. Vulnerable builds invokegit applywith--index,--recount,--cached, and--binary, adding the-3three-way fallback option when the server runs Git 2.32 or later.

An attacker submits the same patch twice to create an add/add collision. The three-way fallback then checks the indexed path out even though the operation uses--cached. Because the temporary clone is bare, its root is$GIT_DIR. An executable file placed athooks/post-index-changetherefore lands inGit's hook directoryand becomes active. Git runs it while updating the index.

The PoC signs in with a normal account, creates an initialized private repository, sends the malicious patch twice, and retrieves the command output. It needs no outbound callback. The hook stores the output in Git objects, creates a branch containing the result, and lets the attacker fetch it over authenticated smart HTTP.

As of July 29, 2026, none of the cited primary sources reports whether the flaw was exploited before or after version 1.27.1 became available.

Successful exploitation gives the attacker the privileges of the Gitea operating-system account. Depending on how the instance is isolated, Gitea said that could expose application and environment secrets, mounted repositories, database credentials and contents, OAuth credentials, and reachable internal services.

Exploitation still requires repository write access, Git 2.32 or later, an enableddiffpatchroute, and a writable, executable temporary filesystem. Default registration lets an outsider obtain the required write access on an unchanged installation.

The fix is easy to miss in the changelog. Gitea changed the temporary clone from bare to non-bare. Thecode commentexplicitly warns that Git commands using--indexmay operate on the working tree. The change was merged and backported on July 26, 2026.

Version1.27.1 shippedon July 27, and the security advisory followed on July 28. The release notes listed the change under MISC as "refactor: git patch apply," not under SECURITY.

Rod hadpreviewed the RCE alongside a separate file-inclusion issue, with a PoC retrieving/etc/passwdfrom a Gitea 1.27.0 host. That issue appears to correspond to a separatechange included in 1.27.1that altered Gitea's Org-mode renderer so#+INCLUDEpaths are returned as plain text instead of being read from the server's filesystem. Gitea has not published a separate advisory or CVE for the file-inclusion issue.

Cybersecurity Webinars

How to Secure AI Code Before It Reaches Production

Learn how 300 enterprise leaders are managing AI-driven open-source risk, remediation debt, and governance at scale.

How to Secure AI-Built Software at Machine Speed

Learn how to govern risk, secure AI-built software, and keep control as development moves at machine speed.

A Look Inside Lasso's AI Security Platform

Claude Runs Across Six Surfaces in Your Company. Your Security Team Sees One.

How to Make Social Engineering Unprofitable

The New Insider Has No Pulse: Securing Privilege When the Actor Is an AI Agent

Get the latest news, expert insights, exclusive resources, and strategies from industry leaders, all for free.